Software products must be flexible to adapt to the needs of the user. Software products developed in one country that seek an international presence must be modified to fit the needs of markets in other countries. For example, spreadsheets are used in many disciplines by users all over the world, but many spreadsheet programs are developed using underlying assumptions (i.e. monetary symbols, fractional representations) based on the country in which the program is developed. In order for a user in another country to use the spreadsheet program, the user must spend many hours customizing the program to meet her particular needs. Another example of programs that are typically culture-specific are help programs. Modifying a help program to be responsive to the needs of a user in another country involves much more than simply translating error messages.
Internationalization is the process of removing language and cultural dependencies from software applications. Localization is the process of reinserting a specific set of values for the language and cultural attributes removed during internationalization. Developers must be aware of the cultural dependencies in localizing their applications. How well a developer internationalizes and localizes its application may be the single biggest factor in determining the success or failure of an organization's products in other countries.
One issue involved in internationalizing and localizing an application is language translation. When translating an application, developers must be concerned with the accuracy of the translation, the introduction of defects during the translation process (i.e. the introduction of defects into an application that were not previously present), and maintenance for every translated version of the application.
However, language translation of applications alone is not enough to make an application internationalized. User interfaces are highly graphical and contain more than simple text strings. Graphical user interface systems have made applications easy to use, but have also made these same applications highly culturally dependent. For example, the color red may indicate "stop" or "warning" in one culture, and have an entirely different meaning, such as "go," in another culture. Thus, an application which uses a red icon as a warning flag, may need to use a different color icon in a different country.
The process of localizing an application for a different country or culture is simply too complex and time-consuming to do individually for each culture. What is needed is a process for simultaneously developing software for all cultural markets. It is important that this process remain consistent with modern software engineering standards for it to be effective. The internationalization process must be capable of being incorporated into current software development methodologies, such as object oriented development and functional decomposition.
Several prior art attempts have been made to arrive at a standardized procedure for solving internationalization issues. For example, one type of international product model enables all groups involved in internationalization to share a common understanding of the components that make up an international product. These components include an international base component, a user interface component, a market specific component and a country specific information component. The international base component contains an application's basic functional code, such as executable images, internal data files, and command procedures without text. The user interface component is language specific and is localized to meet the cultural requirements of the specific group of users. The market specific component meets the special requirements of a specific region and provides enhancement only. The country specific information component is a set of required documentation needed to meet regulations for selling a product in a specific country. One disadvantage of this prior art approach is that it places a large burden of internationalization/localization on local programmers and translators, rather than providing localized interfaces inside of the base operating system. This methodology requires that multiple translations be done for similar information by programmers writing applications for the same operating system.
Another approach is to use national language support (NLS), which provides developers with a library to aid in the internationalization/localization process. NLS includes a set of routines to replace the standard program libraries, along with a set of tools to assist in the construction of message catalogs and local databases. Message catalogs contain textual information that an application might require during localization. These catalogs are then further broken down into sets for ease of interaction. Applications make a request to the NLS system at run time. The NLS then returns a particular word or phrase in the current language. The disadvantage of this approach is that NLS applications require mapping of standard routines into NLS routines, and generation extraction of the messages catalogs. In addition, the NLS approach only allows for the localization of textual and numeric information. It does not handle graphical or auditory information.
A similar prior art NLS approach is used in windows-type systems, such as Microsoft Windows (Microsoft Windows is a trademark of Microsoft Corporation). To help facilitate internationalization/localization in a windows environment, the window subsystem provides NLS application programmer interfaces (APIs), which give applications access to culturally correct string comparisons, collation tables for sorting different languages, date, time, and currency formatting functions, and functions to determine which locale is in effect and which other locales are present on the system. In a properly enabled window program, NLS must be isolated from other parts of an application. NLS function calls must be provided at all points where language dependent operations are required. Unfortunately, the windows application in internationalization/localization also only allows for the localization of textual and numeric information. It does not handle graphical or auditory information.
Another approach is used in the OS/2 operating system (OS/2 is a trademark of International Business Machines Corporation). The OS/2 NLS approach consists of two phases, the first being function development and the second being translation. Function development allows a programmer to work in a standard language, such as double byte character set (DBCS) or Unicode characters having Unicode functions. However, the current approach in OS/2 is limited in that it urges programmers to separate localizable information into resource files. This means that localization teams must then repeatedly translate similar material, rather than having it be part of the base operating system.
Currently, there exists a notion of a locale object. Note that the locale object as it exists in the prior art is not a true object, because it does not encapsulate localization data with the operations that work on the data. The locale object contains support for formatting of time, date and currency information along with support for collation of strings. However, the prior art type of locale object is not readily extendable to allow for the addition of new cultural attributes. Prior art locale objects do not support graphical localization information such as icons, dialogues, menus, and colors, and also do not support sound localization information such as warning, success, and failure beeps. Moreover, prior art locale objects do not support textual localization information such as warning, success, and failure messages.
Finally, prior art locale objects do not allow an application to be configured in such a manner as to allow the application to utilize context sensitive cultural profiles. In other words, prior art locale objects force an entire application to use the same cultural profile for all aspects of the application. This means that an application can not have an interaction cultural profile (i.e. toolbar, commands, etc.) which is separate and distinct from its data cultural profile (i.e. data formats, date formats, paper size, currency and numeric formats, etc.). Furthermore, in an application which contains more than one window, every window of the application must use the same cultural profile. This is a distinct drawback of prior art locale objects. A user in one country often has a need, for example to write a letter or construct a spreadsheet, for a user in another country. For example, suppose a Japanese company wishes to propose a joint manufacturing venture to a German company. The users putting the proposal together will prefer to work using a Japanese interaction cultural profile. This means that menu bars, icons, titles, etc. will all be configured for a Japanese user. However, the letters to the German company should be written in German, and the spreadsheets used to show financial effects should show currency amounts in marks, rather than yen. Prior art locale objects require that the interaction cultural profile and the data cultural profile be the same.
Consequently, there is a need for a system and method which allows users of an information handling system to have access to separate and unique cultural profiles at application run-time. It would be desirable to allow an application to use different cultural profiles in different contexts. Additionally, it would be desirable to enable cultural profiles of an application to be dynamically changed while the application is running.